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Contracts require the Works to be completed by a set date, subject to the Contractor's entitlement of 
extensions of time under the Conditions of Contract. 

The Conditions of Contract usually recognise that if the Contractor is delayed in the completion of the Works 
by the defined risk items and had given notice and particulars of its claim, the Engineer should grant an 
extension of time as may be justified in the circumstances. 

In the following notes, Trett Consulting's Tony Farrow summarises some pertinent points with respect to 
approaches for investigating project delays and the assessment of causation and entitlement to extensions 
of time. 

Most Conditions of Contract do not define how delay is to be established, what detailed particulars the 
Contractor is to provide or how the Engineer is to justify and so fix the extension of time. 

Hence, we need to carry out exercises in order to assist the investigation of why projects run late and to 
assess what delay may have been caused by particular events or the many situations and circumstances that 
frequently arise on construction projects. This work can then be of assistance in the review of causation of 
delay and entitlement under the terms of the particular contract. 


1. Selecting Methods of Delay Analysis? 

Programming software is now regularly used to plan and manage building projects. Software packages vary, 
with price usually influencing the detail and sophistication of the package. At the cheapest level, packages 
provide an ability to produce bar (gantt) charts with little or no data processing facilities and limited graphics 
output. At the top end, packages allow programmes of many thousands of activities to be developed, using 
complex critical path analysis techniques and providing database facilities which provides the basis for 
analysing labour, material and plant resources, as well as drawings, procurement, quantities of work etc. 
They also provide comprehensive graphic facilities. 

These software packages have been developed to assist organisations in the execution of projects. However, 
they are also increasingly used in the area of extension of time analysis, to such an extent that there is a 
growing body of knowledge on this topic. In November 2001, I wrote a paper for the Society of Construction 
Law which discussed some of the methods of analysis used in this field and how different methods produce 
different results. It also considered aspects of good and not so good practice. The paper is entitled 
'Extension of Time Analysis: Methodology and Mythology'. 

In this paper, I outline two broad approaches to delay analysis; theoretical and actual. The theoretical 
methods do not necessarily consider what delay actually arose but seek to demonstrate what might have 
been the delay arising from particular events. The actual-based methods focus on identifying where or when 
delay arose and identifying the events or circumstances giving rise to it. 

Approaches to delay analysis can also be categorised as prospective methods and retrospective methods. 
When a project is in progress and the Contractor and Engineer forecast the impact of known events and 


their impact on the future completion date, an estimate of the prospective situation is made and an 
extension of time is considered. On the other hand, if the project is complete and the events and their 
consequences have run their course, the analyst is able to retrospectively consider what has occurred and 
make assessments after-the-event. 

The Society of Construction Law's 'Delay and Disruption' protocol (sometimes referred to as the Extension of 
Time protocol) recognises these points. Essentially, if the project is 'live' and one is making judgements 
about the future, then the analysis is based on the known facts to-date and assessments about the future 
i.e. one might call the future assessment a theoretical prediction of what might occur. However, if the 
project is complete, the parties should be able to consider the real facts in the case and seek to identify 
what did occur i.e. this is an assessment of what actually arose. Hence the SCL Protocol distinguishes 
between live projects and completed projects. 

In practice, all methods of analysis have an element of theory or estimation and no analysis is solely a factual 
investigation because records are never as complete as one would like and the process demands the 
application of many assumptions, which are usually subjective and personal. However, the moretheoretical 
the method of analysis, the wider is the range of potential outcomes when applying the same set of facts or 
assumptions to different methods. Hence, from a methodological point of view, the analysis is less reliable. 
This is a fact of life if one is dealing with prospective situations, but in cases where the project is complete, 
the analysis can be more rigorous by the use of methods that focus on the actual situation, not theory. 


2. As-planned programme 

A number of the methods of analysis involve the use of the asplanned programme. This is the 
representation of the project, in programming terms, at the start of the Works. It can be an important 
document since it acts as a reference point to explain what happens during the project and how the live 
project differed from the initial plan. 

The contract may require the Contractor to submit a programme shortly after contract award. The Parties 
use this to monitor progress and events. It is normal to adopt this programme as a basis for the asplanned 
programme. However, at the commencement of the project, the Contractor is not aware of all matters and 
as progress is made, the initial programme is updated and revised, with new projections about the 
remaining works to completion. Hence, the as-planned programme should not be seen as a single 
programme and in delay-analysis, one should recognise and consider the Contractor's updated intentions 
and expectations. This point is emphasised in the SCL Protocol i.e. it recommends the use of updated 
programmes to analyse delay events, not to analyse all delay events using a single, original, baseline 
programme. 

When undertaking a retrospective, forensic examination of delay on a project, the initial as-planned 
programme may be deficient in certain respects, in terms of structure, activities, logic, criticality, detail and 
accuracy. For example, a particular element of the project which has been subject to delay-events, may not 
be shown on the as-planned programme, or is not identified in the necessary level of detail. In these 
situations, the analyst has to adjust the as-planned programme to make it possible to carry out an 
assessment of delay. 

However, developing the as-planned programme in greater detail can produce arguments. Hindsight is a 
wonderful gift of the delay analyst and one can always come up with a sound argument to justify the 
sequence in which a particular element of unplanned work would have been carried out, as well as its 


duration. Consequently, the more hindsight that is applied to your methodology, the greater the 
opportunity for challenge on the grounds of bias or unreliability. If you do not have an as-planned 
programme in sufficient detail, think twice about developing a very complex plan. 

From the methodological perspective, therefore, one should try and limit the modifications to 
contemporaneous documents. 


3. As-built programme 

Given that the as-planned programme is used as a baseline for measuring variance, the as-built programme 
is used to establish what actually transpired and from this, one establishes the delta between the plan and 
the actual. The investigation continues with an exploration of the causes of the delta. Hence, the agreement 
of as-built records is an important task as it can remove a great deal of the factual debate regarding 
extensions of time. The as-built programme can be derived from several sources. The most common are 
progress records, where the Contractor or the Engineer, or both, assess the production achieved each 
month by reference to the programme of work. The assessment is usually based on a percentage of the 
work complete. An alternative source is the monthly valuation of the work completed, which ought to 
correlate with the progress records but does not always. The progress and valuation as-built records can be 
supplemented by other records such as subcontractor information, photographs, correspondence, diary 
records etc. 

The difficulties in establishing asbuilt records include the use of inaccurate data. For example, a Contractor 
may overstate the amount of work complete or the QS may understate the amount earned. There is a 
general tendency for the early progress to be over optimistic and the completion of the final '10%' of an 
activity to take considerably longer than its straight-line prediction. However, there should be less debate 
about the as-built situation than the as-planned programme. 


4. Critical Path Analysis 

Critical path analysis is a mathematical and logic tool that can be used to predict how long it will take to 
complete a series of activities. Many project management software packages use the technique to allow a 
planning model of a project to be developed which is then used as a management tool during project 
execution. A Contractor's programme created using critical path analysis allows the parties to identify which 
parts of the project, or which activities, are critical and those which are non-critical. A critical aspect of the 
project is one where the timescale is recognised as being 'tight' and that any problems or delays to tasks in 
that aspect of the works may likely delay the overall project. A noncritical aspect of the project, on the other 
hand, is one where there is plenty of time available to carry out the various tasks (there is 'float') and that 
any delay to these is unlikely to effect the project-end date. 

What is a critical and what is a non-critical aspect of the project is ultimately derived from the project 
management software but in reality, it is the input that dictates the output. By this I mean that the person 
preparing the programme defines the criticality of the elements of the project, not the software. For 
example, the structure of the programme, the activity durations and the logic links between activities is 
defined by the programmer and the software programme uses this information to establish 
criticality.Change the structure, durations and links and the software programme will change the criticality. 

Criticality can also be dependant upon organisation structure and resources. A plan to utilise one earthwork 
subcontractor and three tower cranes is likely to have a different critical path than a plan to utilise three 


earthwork subcontractors and five tower cranes. 


Criticality will change as the project develops. This is because the assumptions made in the original plan may 
not reflect what actually arose or because the programmer changes the assumptions in the ongoing plan, 
based upon latest knowledge and revised actions or methods of working by the Contractor or Engineer. 
Hence, when undertaking retrospective extension of time analysis, one should not hold on to a single critical 
path programme for the project because this was never the case in practice. 

From the methodological point of view, what is important to recognise is that critical path analysis involves a 
great deal of underlying assumptions which are not factual but are preferences and so subject to a range of 
opinion. Consequently, different analysts can produce wideranging results using the same factual data 
because they hold different views regarding methods of working, sequences of building and resources for 
construction; all reasonable but each leading to different critical paths. 

The more the number of activities in a programme, the greater will be the number of logic links between 
them and so greater will be the number of assumptions involved in completing the model. Hence, it is 
possible that when carrying out retrospective delay analysis using critical path analysis, large programmes 
with hundreds and thousands of activities will produce unreliable results. This is because the analyst has 
made hundreds of assumptions with respect to preparing the programme and when considering the impact 
of an event, he or she makes a single adjustment, whereas in practice, a programmer would likely make 
many adjustments to a programme if faced with a potential delay. This is project management. 

Finally, it is important to recognise that it is easy to manipulate a critical path programme in order to derive 
the required end result. For example, if a programmer wishes to make a certain section of the work critical, 
he achieves this by fixing durations of activities or logic links between activities. Equally, if there has been 
variations issued in one part of the works, it is possible to make this element of the programme critical, so 
that the introduction of the variations will have a delaying effect on the overall project. This is another 
reason why it is worth considering reducing the number of activities on very large programmes used in 
retrospective delay analysis. 


5. Other Issues 

In carrying out planning exercises to assess delay, it is sometimes necessary to deal with a number of other 
issues. These include ownership of programme float, concurrency of delay events and dominance theory. 


6. Concurrency 

The SCL Protocol defines concurrency in the following way (Appendix A, page 53): 

True concurrent delay is the occurrence of two or more delay events at the same time, one an Employer Risk 
Event, the other a Contractor Risk Event and the effects of which are felt at the same time. The term 
'concurrent delay' is often used to describe the situation where two or more delay events arise at different 
times, but the effects of them are felt (in whole or in part) at the same time. To avoid confusion, this is more 
correctly termed the 'concurrent effect' of sequential delay events. 

Essentially, concurrency seeks to consider the situation where both the Employer and the Contractor are 
causing delay and the question is, does the Contractor get an extension of time? The proposition in the SCL 
Protocol is that the contractor does get the extension of time but he is only entitled to any extra costs 


(damages or loss and expense) incurred as a specific consequence of the employer-caused delay. This 
basically means that if the Contractor is able to identify extra costs at the activity or event level, he recovers 
these but not the general running costs of the project (refer to paragraph 1.10.4 of Guidance Section 1). On 
the other hand, the Employer foregoes recovery of liquidated damages. 

Examples of the SCL Protocol's position on concurrency are set out in its Appendix D but there are a number 
of very important issues to consider: 

The Protocol is possibly at odds with English Law, which it recognises at paragraph 1.4.11 of Guidance 
Section 1. The alternative position on concurrency is that the most 'dominant' delay event (which might be 
considered the longest or most critical) decides liability and entitlement. Hence, to follow the Protocol could 
be to ignore the law (that is, unless the parties have signed-up to the Protocol). 

It is argued that concurrency only occurs where two events are actually delaying the progress and 
completion of the project. For example, if a Contractor is digging out a basement on Monday but his plant 
breaks down and production stops, it is said that he cannot claim there was a concurrent delay on Monday 
because he still had not received the next set of drawings which would allow him to progress with the next 
stage of the basement. Only when the contractor had finished the digging of the basement and was ready to 
commence the next stage, would the works be delayed by outstanding drawings. Essentially, it is said that 
any event must be delaying or impeding current progress for it to be considered a 'delay event'; when there 
are two or more of these events occurring at the same time, then there is concurrency. 

If the project is in delay for which there is no entitlement of extension of time and an Employer causes a 
further delay after the contractual date for completion by issuing a late variation or changed requirement, it 
is said that the Contractor's entitlement is assessed on the 'net' method not the 'gross' method. By this, I 
mean that the extension of time is calculated by reference to the period of time needed to deal with the 
Employer-caused event, and this period is added on to the contract completion date; one does not consider 
the timing of the event and measure delay from that date. 


7. Ownership of programme float 

I mentioned earlier that there are critical and non-critical parts of a programme. Delays to critical parts 
cause the project's end date to overrun whereas delays to noncritical parts will only cause the project's end 
date to overrun when the entire available float on that part has been used up. A common question in delay 
analysis is, if an Employer causes delay and uses up the float, is a Contractor entitled to be compensated for 
the loss of it? 

If the project owns the float, then the party using it first has the benefit. If the Contractor owns the float and 
the Employer uses it, the Contractor ought to be compensated, either by the return of the float or by 
payment of extra cost. 


8. Dominance Theory 

I have mentioned that where there are two or more events causing delay to the project at the same time, 
this is termed concurrency. Where there are concurrent Employer-caused and Contractor-caused delays, 
there is a legal argument which says that the delay is allocated to the more dominant of the concurrent 
events. Hence, if the dominant event is found to be an Employer risk event, then a Contractor is awarded an 
extension of time for the delay. However, if the dominant event is a Contractor risk event, no extension is 
allowed. 


All these issues need to be considered against the facts of the case, the terms of the contract and the laws 
governing the contract. 



